home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 995 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB

  1. From: abell@mindspring.com (Andrew Bell)
  2. Message-ID: <4k7c9s$t5e@mule1.mindspring.com>
  3. X-Original-Date: Sun, 07 Apr 1996 03:22:53 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 07 Apr 96 08:13:28 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Return-Path: <daemon@meeker.UCAR.EDU>
  8. Newsgroups: comp.std.c++
  9. Subject: Re: constness of private members and methods
  10. Organization: MindSpring Enterprises
  11. References: <m0u3992-000GcEC@7.kurahaupo.gen.nz> <3161eaa4.8216104@nntp.ix.netcom.com> <4jvcrn$ch2@mule1.mindspring.com> <4k3q10$7bd@hermes.synopsys.com>
  12. X-Newsreader: Forte Agent .99.82
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMWd5PuEDnX0m9pzZAQFjxwF+JurnZbBD1IbQzGoShA0qY8lty284znTy
  15.     du0gFsuUbOllrizxItO7m3563CShd2Zb
  16.     =Gi/H
  17.  
  18. jbuck@Synopsys.COM (Joe Buck) wrote:
  19.  >abell@mindspring.com (Andrew Bell) writes:
  20. >>The problem is the compiler needs to know the "purity" of the
  21. >>functions a given function calls during its compilation, or it can't
  22. >>optimize the code.  You would thus have to compile all the called
  23. >>functions first,
  24.  
  25. >No, you wouldn't. 
  26.  
  27. Tsk, tsk, Joe, you misidentified someone else's statements as Jason's,
  28. and then edited out the part I was responding to, thus making it look
  29. like I was responding to something I wasn't.  I was responding to
  30. Jason's comment that "pure" and "clean" as modifiers weren't necessary
  31. with a slightly smarter compiler.  My response was that in that case,
  32. all the code would have to be precompiled for purity/cleanliness,
  33. before anything could be compiled, a statement I still stand by.
  34.  
  35. >>With the proposed idea, a function that claims to pure and isn't would
  36. >>be tagged with a compiler error.  This might be problematic with
  37. >>templates, as instantiation for a particular type may lead to non-pure
  38. >>functions being called.
  39.  
  40. >Replace "pure" with "const".  It's no different.
  41.  
  42. In that case, pure would have to be part of the function
  43. prototype(specification? Not sure if I'm using the right term here),
  44. which would increase its impact on the language specification.  It
  45. also means you could conceivably have both pure and impure (*) and
  46. clean and unclean versions of the same function, though you could
  47. restrict it to not allow this.  
  48.  
  49. I suspect the standardization committee might be reluctant to make
  50. such a change just for optimization reasons (especially at this
  51. point), but maybe there will be a C++ '98 or some such.  (Gotta be,
  52. for my wrappers proposal! :-)
  53.  
  54. Andrew Bell
  55. abell@mindspring.com
  56.  
  57. * Although impure functions might be illegal in functions that might
  58. be used by children because of the Exon Amendment....
  59. ---
  60. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  61. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  62. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  63. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  64. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  65.